home *** CD-ROM | disk | FTP | other *** search
/ Aminet 13 / Aminet 13 - August 1996.iso / Aminet / comm / fido / MM_AmiHatch.lha / MM / Docs / MM_AmiHatch.Dok < prev   
Text File  |  1996-06-08  |  10KB  |  309 lines

  1.  
  2.  
  3.  
  4.                                   L   L  L   L
  5.                                   LL LL  LL LL
  6.                                   L L L  L L L
  7.                                   L   L  L   L
  8.                                   L   L  L   L
  9.  
  10.  
  11.                 LLL   L   L  LLL  L   L   LLL   LLLLL   LLL   L   L
  12.                L   L  LL LL   L   L   L  L   L    L    L   L  L   L
  13.                LLLLL  L L L   L   LLLLL  LLLLL    L    L      LLLLL
  14.                L   L  L   L   L   L   L  L   L    L    L   L  L   L
  15.                L   L  L   L  LLL  L   L  L   L    L     LLL   L   L
  16.  
  17.  
  18.                            L   L  LL     LLLL  LLLL
  19.                            L   L L  L    L     L
  20.                            L   L L  L    LLL   LLL
  21.                             L L  L  L       L     L
  22.                              L    LL  L  LLL   LLL
  23.  
  24.  
  25.  
  26.  
  27.                          (C)  1996  ULRICH LAMMERS
  28.                           Alle Rechte vorbehalten
  29.  
  30.         Dieses Arexx-Script benötigt den MailManager von Pino Alberti
  31. ------------------------------------------------------------------------------
  32.  
  33.  
  34.  
  35.  1. Einführung
  36.  =============
  37.  
  38.   1.1 Rechtliches
  39.   ---------------
  40.  
  41.    MM_AmiHatch ist ein Utility für den Mail Manager von Pino Aliberti um die
  42.    AMINet-Archive aus dem InterNet mit ihren RENAMING-Files besser handeln zu
  43.    können.
  44.    Für diejenigen, die Ihr System als AmiNet-Mirror nutzen, ist das eine
  45.    enorme Arbeitserleichterung, das die gesamte Verarbeitung der
  46.    aminet_xxxxx_xxxxx.lha sowie der ___RENAMING_xxxxx_xxxxx von dem Script
  47.    übernommen wird.
  48.  
  49.    Die Programme und Dateien dieses Archives sind frei kopierbar, das Copyright
  50.    liegt allerdings bei © Ulrich Lammers. Das Archiv darf frei weitergegeben
  51.    und verbreitet werden, solange dafür nicht mehr Geld verlangt wird, als für
  52.    das Kopieren notwendig ist.
  53.  
  54.    Eine kommerzielle Nutzung ist ohne die schriftliche, vorherige Erlaubnis des
  55.    Autors verboten. Dieses Archiv und alle seine Einzeldateien müssen
  56.    unverändert bleiben, es dürfen keine Veränderungen oder Erweiterungen
  57.    vorgenommen werden.
  58.  
  59.    MM_AmiHatch ist Mailware :-). Das bedeutet, wenn Du dieses Programm länger
  60.    als dreißig Tage nutzt, schicke dem Programmierer bitte eine kurze Mail,
  61.    dass Du dieses Programm nutzt. In dieser dürfen auch kritische Anmerkungen
  62.    und Feature-Requests enthalten sein... es ist frustrierend Programme zu
  63.    schreiben von denen man nicht weiß ob sie jemand nutzt, ob sie Sinn machen
  64.    oder nicht.
  65.  
  66.    Die einzige Bedingung um MM_AmiHatch zu nutzen, ist die Beachtung dieser
  67.    wenigen Auflagen.
  68.  
  69. ==============================================================================
  70.    Der Autor ist für irgendwelche aus der Nutzung dieses Programms
  71.    resultierenden Probleme oder Datenverluste NICHT verantwortlich.
  72. ==============================================================================
  73.  
  74.  
  75.   1.2 Generelles
  76.   --------------
  77.  
  78.    Dieses ist mein erstes veröffentlichtes ARexx-Programm für den MailManager.
  79.    Sicherlich können noch einige Optimierungen, neue Features etc. Einzug
  80.    finden. Also seid bitte nicht zu hart in Eurer Beurteilung. Seinen Zweck
  81.    erfüllt es allemal, und das sogar sehr gut. (auf meinem System zumindest..)
  82.  
  83.  
  84.   1.3 Autor
  85.   ---------
  86.  
  87.    Wenn Du irgendwelche Verbesserungsvorschläge oder Probleme mit diesem
  88.    Programm hast, vielleicht sogar einen nicht existenten Bug gefunden hast, so
  89.    lasse es mich wissen.
  90.  
  91.    Zu erreichen bin ich folgendermassen:
  92.  
  93.       Ulrich Lammers
  94.       Alter Pferdemarkt 3       39:178/0.0@AmigaNet
  95.       49808 Lingen               2:2426/4065.0@FidoNet
  96.       Telefon 0591/9150115
  97.  
  98.  
  99.  
  100.  2. Features
  101.  ===========
  102.  
  103.   MM_AmiHatch...
  104.  
  105.      ... zerlegt die aminet.xxxxx.xxxxx.lha Files in Ihre Komponenten,
  106.          führt ein automatisches Renaming durch und kopiert die Files in Ihr
  107.          passendes Zielverzeichnis.
  108.      ... hatched alle neuankommenden Files für angeschlossene Nodes/Points nach
  109.          Massgabe des MM_Config Files
  110.      ... erstellt nicht existente TickAreas nach Vorgabe
  111.      ... erstellt AutoLinks für neue TickAreas
  112.      ... erstellt Zielverzeichnis in Baumstruktur oder flach, was von einigen
  113.          BBS-Systemen (Excelsior!) gefordert wird.
  114.      ... erstellt NewArea-Announces in beliebiger Area
  115.      ... kann Einträge von neuen Areas in die FFRS-Konfiguration vornehmen
  116.  
  117.  
  118.  
  119.  3. Installation
  120.  ===============
  121.  
  122.   1. Kopiere die Dateien in die entsprechenden MM: Verzeichnisse
  123.  
  124.   2. Verändere die .CFG nach Deinem Gusto.
  125.  
  126.   3. Füge ein rx MM:Rexx/MM_AmiHatch bei Deinem TIC-Import ein. Ich empfehle die
  127.      Nutzung von MM_ImportPlus (© Robert Hofmann) "#TICKCMD..."
  128.  
  129.  
  130.  
  131.  4. Benutzung
  132.  ============
  133.  
  134.   [RX] MM_AmiHatch[.rexx]
  135.  
  136.   Wie dem geneigten Nutzer vielleicht aufgefallen ist, befindet sich ein
  137.   weiteres Script in der Distribution, nämlich "MM_AmiHatch". Das ist ein
  138.   Ausführbares Programm, das mit CompressRexx2.1 erstellt wurde. Es lässt sich
  139.   wie ein normales Programm starten, BENÖTIGT ABER TROTZDEM AREXXMAST zur
  140.   Funktion.
  141.  
  142.  
  143.  
  144.  
  145.  5. Konfiguration
  146.  ================
  147.  
  148.   MM_AmiHatch kann schon fein seine Konigurationsdaten aus einem Konfig-File
  149.   einlesen.
  150.   Im folgenden sind alle Konfigurationsparameter einzeln erläutert. Schau Dir
  151.   bitte die Beispiel-Konfiguration genau an!!
  152.  
  153.  
  154.     5.1 #INBOUND    DIR/A
  155.     ---------------------
  156.  
  157.     Pfad zu Deinem Verzeichnis, in dem die aminet_xxxxx_xxxxxx.lha und
  158.     ___RENAMING.xxxxx.xxxxx Dateien liegen.
  159.  
  160.     Bsp.: #INBOUND  Work:Aminet_Hold/
  161.  
  162.  
  163.     5.2 #WORKDIR    DIR/A
  164.     ---------------------
  165.  
  166.     Das Arbeitsverzeichnis für MM_AmiHatch, in dem die Archive ausgepackt werden. 
  167.  
  168.     Bsp.: #WORKDIR  Boot:Temp/
  169.  
  170.  
  171.     5.3 #DESTINATIONPFAD    DIR/A
  172.     -----------------------------
  173.  
  174.     Hier werden die (neuanzulegenden) TickAreas erstellt.
  175.  
  176.     Bsp.: #DESTINATIONPFAD  Aminet:
  177.  
  178.  
  179.     5.4 #ARCHIVEPREFIX      NAME/A
  180.     ------------------------------
  181.  
  182.     Das ist der Namensprefix der zu bearbeitenden AmiNet-Archive.
  183.  
  184.     Bsp.: #ARCHIVEPREFIX    aminet_
  185.  
  186.  
  187.     5.5 #BACKUPDIR      DIR/A
  188.     -------------------------
  189.  
  190.     Der Pfad zum BackUp-Directory, wo verarbeitete Archive und ___RENAMING-Files
  191.     abgelegt werden. Ohne Namensangabe werden die Files einfach gelöscht.
  192.  
  193.     Bsp.: #BACKUPDIR    MAIL:MM_BACKUP/
  194.  
  195.  
  196.     5.6 #AUTOLINKNODE <Node>[<Node> <Node> <Node>...]
  197.     -------------------------------------------------
  198.  
  199.     Hier werden alle Nodes/Points, also Systeme eingetragen, welche die NEU
  200.     ERSTELLTEN Areas als Autolink sofort erhalten sollen (z.B. Downlinks die
  201.     ebenfalls AmiNet-Mirror sind)
  202.  
  203.     Bsp.: #AUTOLINKNODE 39:170/1 110 178/111 .1 .12
  204.     Hierbei würden die Nodes 39:170/1, 39:170/110, 39:178/111 sowie die Points .1 und .12
  205.     von 39:178/111 die neuen Areas erhalten.
  206.  
  207.  
  208.     5.7 #HATCHNODE      <Node>/A
  209.     ----------------------------
  210.  
  211.     Dieses ist die Absende-Adresse des Systems für die TIC-Files.
  212.  
  213.     Bsp.: #HATCHNODE    39:178/1.0@AmiNet
  214.  
  215.  
  216.     5.8 #GROUP      <gruppe>
  217.     ------------------------
  218.  
  219.     Die Gruppe, die in dem neuen TickArea Eintrag im MM_CFG eingetragen
  220.     werden soll. Muß eine gültige Gruppe der MM_CFG sein.
  221.  
  222.     Bsp.: #GROUP    AMINET-FILES
  223.  
  224.  
  225.     5.9 #LEVEL      <num>
  226.     ---------------------
  227.  
  228.     Der Level, der in dem neuen TickArea Eintrag im MM_CFG eingetragen werden
  229.     soll.
  230.  
  231.     Bsp.: #LEVEL    50
  232.  
  233.  
  234.     5.10 #NEWAREA   [Tree|NoTree]
  235.     -----------------------------
  236.  
  237.     Hiermit wird festgelegt, wie die Verzeichnisstruktur der neuen TIC-Areas
  238.     auszusehen hat. Es gibt zwei Möglichkeiten:
  239.  
  240.       TREE   - Die Verzeichnisse werden wie im AmiNet üblich mit
  241.                Unterverzeichnissen angelegt. Also z.B.: AmiNet:COMM/BBS/
  242.                Das ist wohl die Standardeinstellung.
  243.  
  244.       NOTREE - Die Verzeichnisse werden OHNE Unterverschachtelungen im
  245.                Zielverzeichniss angelegt. Das ist für die Verwendung mit einigen
  246.                BBS-Paketen (z.B. Excelsior!) erforderlich, da diese keine
  247.                verschachtelten FileBase-Verzeichnisse unterstützen.
  248.                Also z.B. : AmiNet:COMM_BBS/
  249.  
  250.      Bsp.: #NEWAREA TREE
  251.  
  252.  
  253.     5.11 #KUTTAREAWITH          <Trenner>
  254.     -------------------------------------
  255.  
  256.     Wenn bei #NEWAREA NoTree angegeben wurde, kann hier ein Trennzeichen für die
  257.     Betitelung der Area-Directories angegeben werden.
  258.  
  259.     Bsp.: #KUTTAREAWITH  _ --> AMINET:COMM_BBS/
  260.           #KUTTAREAWITH  . --> AMINET:COMM.BBS/
  261.  
  262.  
  263.     5.12 #ANNOUNCEAREA      <AreaName>
  264.     ----------------------------------
  265.  
  266.     Hiermit kann man angeben, in welche Area die Announcements für die
  267.     Erstellung einer neuen Area geleitet werden sollen. es muß eine
  268.     existierende Area vom MailManager sein.
  269.  
  270.     Bsp.: #ANNOUNCEAREA     POINT.INFOS
  271.  
  272.  
  273.     5.13 #FILEREQUESTSERVER     [FFRS|NONE]
  274.     ---------------------------------------
  275.  
  276.     Hiermit können neue Areas gleich dem FileRequestserver FFRS mitgeteilt
  277.     und freigeschaltet werden. Die .CFG von FFRS wird, sofern der Pfad bei
  278.     #REQUESTSERVERCFG angegeben ist automatisch geändert.
  279.     Es existieren zwei Schlüsselworte, die sich gegenseitig ausschliessen:
  280.         FFRS - Neue Areas werden FFRS mitgeteilt und eingebunden
  281.         NONE - FFRS wird nicht beeinflusst.
  282.  
  283.     Bsp.: #FILEREQUESTSERVER    FFRS
  284.  
  285.  
  286.     5.14 #REQUESTSERVERCFG      <Pfad>
  287.     ----------------------------------
  288.  
  289.     Wenn bei #FILEREQUESTSERVER FFRS eingetragen wurde, kann man jetzt den Pfad
  290.     zu der .CFG von FFRS angeben. Ansonsten hat dieser Eintrag keine Funktion.
  291.  
  292.     Bsp.: #REQUESTSERVERCFG     FFRS:FFrs_1.Cfg
  293.  
  294.  
  295.  6. Ackknowledgements
  296.  ====================
  297.  
  298.     Hier der Dank an die, die dieses Script ermöglicht haben :
  299.  
  300.     Pino Alberti   -  Für seinen superben MailManager...
  301.  
  302.     Robert Hofmann -  Für seine pionierhaften Leistungen in der MM
  303.                       ARexx-Programmierung und den damit verbundenen Inneren
  304.                       Antrieb und guten Tips für das Programm ...
  305.  
  306.     Cord Moeller   -  Für das Tippen der Docs und das Beta-Testing (auch für die
  307.                       lästigen Feature-Requests ?!)
  308.  
  309.